There exists a need to create, access, and process communications (e.g., email or SMS) even when a user does not have access to the Internet or other communications network. For example, many email applications now have “offline” capabilities made possible by synching the user's email account between the email service provider's server and a local database associated with a user, such as a computer, mobile phone, or other communications device. In this way, the user can access information synched to the local database even when the user is offline. This can include, for example, perusing the inbox, searching for archived emails, or drafting new emails. Once the user has regained a connection to the communications network, the user's modifications to her local database are uploaded to the email service provider's server.
Often, however, only one transaction can be executing on the user's local database at any one time. For example, while a user is reading an email from the local database (a “foreground process”) the system may also attempt to write an email to the same database (a “background process”). Transactions from multiple processes can therefore result in delays to one or more of those processes. For example, a foreground process may have a transaction that is waiting in line behind twenty transactions previously submitted to the database by a background process. This can result in a perceivable delay that negatively impacts the user's experience.
Accordingly, there is a continued need for a method and system of processing database transaction requests from both foreground and background processes in a manner that avoids or prevents delays to the user.